This is snot a good idea. If the code that handles user data is broken, and we probably want a test for that in IPA ;) then debugging is basically impossible as one cannot login.

If the code that handles user data is broken

If the code is in EC2 what precludes key-pair code from also being broken?

then debugging is basically impossible as one cannot login.

We also decided that from MASH the instances are not debuggable. So why can't this be an option? Provide optional ssh-key name which takes precedence over user-data.

@rjschwei There's a plethora of ways an instance could end up un-reachable which cannot be distinguished by IPA.

• Might be launched in a subnet which the calling system does not have access to.
• Instance might have failed initialization.
• Possible failure on reboot.
• Mismatching key-pair.
• Incorrect user.
• Local network might be blocking connection.
• Etc. etc.

From an automated testing standpoint all we can do is log a generic failure that instance is not reachable. And fail the test.

Then if ssh-key and user-data were interchangeable options one could manually test both with IPA. So IMHO this would be an advantage. Now the user can use IPA to test cloud-init issues. Otherwise the user would have to use a separate tool/method if debugging cloud-init problem.

Reopening with amended commit. I think allowing for optional ssh key name solves the concern of debugging instances with cloud init issues.

And default use of cloud-init user-data gives an added implicit test for user-data handling in images.

1.) The proposed implementation was not optional, it was for removing the the ssh-key argument having an optional implementation is a different discussion
2.) The ssh-key as "built in" vs. "provided as user data" is a much simpler implementation and a data path that has historically never been broken. However user data execution/injection has been broken.
3.) mash is another level of abstraction where ipa runs in an automated fashion, thus not supporting "debugging" in that environment is a completely different cup of tea.
4.) Most of the other issues you mentioned could be considered "operator errors"

The proposed implementation was not optional

Right, but the PR was closed prematurely without providing an opportunity to discuss possible resolutions for your concerns.

Which I think making it optional is certainly worth consideration. Since that means from an API standpoint nothing that was available in regards to ssh key names has been removed. And if provided the key name is still used by default.

Most of the other issues you mentioned could be considered "operator errors"

Right, but whether or not they are user created doesn't matter. In any of the scenarios IPA cannot provide a more useful error aside from, "The instance is unreachable". But this should be moved to a different discussion thread.